最近升级了一版 kubelet，修复因 kubelet 删除 Pod 慢导致平台删除集群超时的问题。在灰度 redis 隔离集群的时候，发现升级 kubelet 并重启服务后，少量宿主状态变成了 NotReady，并且回滚 kubelet 至之前版本，宿主状态仍然是 NotReady。查看宿主状态时提示 ‘container runtime is down’ ，根据经验，此时一般就是容器运行时出了问题。弹性云使用的容器运行时是 docker，我们就去检查 docker 的状态，检测结果如下：

docker ps 查看所有容器状态，执行正常

docker inspect 查看某一容器详细状态，执行阻塞

典型的 docker hang 死行为。因为我们最近在升级 docker 版本，存量宿主 docker 的版本为 1.13.1，并且在逐步升级至 18.06.3，新宿主的 docker 版本都是 18.06.3。docker hang 死问题在 1.13.1 版本上表现得更彻底，在执行 docker ps 的时候就已经 hang 死了，一旦某个容器出了问题，docker 就处于无响应状态；而 docker 18.06.3 做了一点小小的优化，在执行 docker ps 时去掉了针对容器级别的加锁操作，但是 docker inspect 依然会加容器锁，因此某一个容器出现问题，并不会造成 docker 服务不可响应，受影响的也仅仅是该容器，无法执行任何操作。

至于为什么以 docker ps 与 docker inspect 为指标检查 docker 状态，因为 kubelet 就是依赖这两个 docker API 获取容器状态。

所以，现在问题有二：

docker hang 死的根因是什么？

docker hang 死时，为什么重启 kubelet，会导致宿主状态变为 NotReady？

kubelet 重启后宿主状态从 Ready 变为 NotReady，这个问题相较 docker hang 死而言，没有那么复杂，所以我们先排查这个问题。

kubelet 针对宿主会设置多个 Condition，表明宿主当前所处的状态，比如宿主内存是否告急、线程数是否告急，以及宿主是否就绪。其中 ReadyCondition 表明宿主是否就绪，kubectl 查看宿主状态时，展示的 Statue 信息就是 ReadCondition 的内容，常见的状态及其含义定义如下：

Ready 状态：表明当前宿主状态一切 OK，能正常响应 Pod 事件

NotReady 状态：表明宿主的 kubelet 仍在运行，但是此时已经无法处理 Pod 事件。NotReady 绝大多数情况都是容器运行时出了问题

Unknown 状态：表明宿主 kubelet 已停止运行

kubelet 定义的 ReadyCondition 的判定条件如下：

深入 nodestatus.ReadyCondition 的实现可以发现，宿主是否 Ready 取决于很多条件，包含运行时判定、网络判定、基本资源判定等。这里我们只需关注运行时判定即可：

当出现如下两种状况之一时，则判定运行时检查不通过：

距最近一次运行时同步操作的时间间隔超过指定阈值（默认 30s）

运行时健康检查未通过

那么，当时宿主的 NotReady 是由哪种状况引起的呢？结合 kubelet 日志分析，kubelet 每隔 5s 就输出一条日志：

因此，状况 1 是宿主 NotReady 的元凶。

我们继续分析为什么 kubelet 没有按照预期设置 lastBaseRuntimeSync。kubelet 启动时会创建一个 goroutine，并在该 goroutine 中循环设置 lastBaseRuntimeSync，循环如下：

由于某个容器状态异常，kubelet 执行 docker inspect 操作也被 hang 死。

因此，重启 kubelet 引起宿主状态从 Ready 变为 NotReady，其根因在于某个容器状态异常，执行 docker inspect 时被 hang 死。而如果 docker inspect hang 死发生在 kubelet 重启之后，则不会对宿主的 Ready 状态造成任何影响，因为 oneTimeInitializer 是 sync.Once 类型，也即仅仅会在 kebelet 启动时执行一次。那时 kubelet 仅仅是不能处理该 Pod 相关的任何事件，包含删除、变更等，但是仍然能够处理其他 Pod 的任意事件。

可能有人会问，为什么 kubelet 重启时访问 docker inspect 操作不加超时控制？确实，如果添加了超时控制，kubelet 重启不会引起宿主状态变更。待详细挖掘后再来补充，我们先继续分析 docker hang 死的问题。

我们对 docker hang 死并不陌生，因为已经发生了好多起。其发生时的现象也多种多样。以往针对 docker 1.13.1 版本的排查都发现了一些线索，但是并没有定位到根因，最终绝大多数也是通过重启 docker 解决。而这一次发生在 docker 18.06.3 版本的 docker hang 死行为，经过我们 4 人小分队接近一周的望闻问切，终于确定了其病因。注意，docker hang 死的原因不止一种，因此本处方并非是个万能药。

现在，我们掌握的知识仅仅是 docker 异常了，无法响应特定容器的 docker inspect 操作，而对详细信息则一无所知。

首先，我们希望对 docker 运行的全局状况有一个大致的了解，熟悉 go 语言开发的用户自然能联想到神器 pprof。我们借助 pprof 描绘出了 docker 当时运行的蓝图：

注意，这是一份精简后的 docker 协程栈信息。从上面的蓝图，我们可以总结出如下结论：

有 717594 个协程被阻塞在 docker inspect

有 4175 个协程被阻塞在 docker stats

有 1 个协程被阻塞在获取 docker exec 的任务 ID

有 1 个协程被阻塞在 docker exec 的执行过程

从上面的结论，我们基本了解了异常容器 hang 死的原因，在于该容器执行 docker exec 后未返回 (4)，进而导致获取 docker exec 的任务 ID 阻塞(3)，由于(3) 实现获取了容器锁，进而导致了 docker inspect (1)与 docker stats (2) 卡死。所以病因并非是 docker inspect，而是 docker exec。

要想继续往下挖掘，我们现在有必要补充一下背景知识。kubelet 启动容器或者在容器内执行命令的完整调用路径如下：

dockerd 与 containerd 可以当做两层 nginx 代理，containerd-shim 是容器的监护人，而 runc 则是容器启动与命令执行的真正工具人。runc 干的事情也非常简单：按照用户指定的配置创建 NS，或者进入特定 NS，然后执行用户命令。说白了，创建容器就是新建 NS，然后在该 NS 内执行用户指定的命令。

按照上面介绍的背景知识，我们继续往下探索 containerd。幸运的是，借助 pprof，我们也可以描绘出 containerd 此时的运行蓝图：

同样，我们仅保留了关键的协程信息，从上面的协程栈可以看出，containerd 阻塞在接收 exec 返回结果处，附上关键代码佐证：